The transmission control protocol (TCP) is one of the most widely used and reliable data transport protocols across communications networks. One of TCP's primary distinctions and the reasons for its widespread use is a robust algorithm to share bandwidth between current TCP sessions. This sharing algorithm within TCP is generally know as “congestion control” since it attempts to avoid the problems of network congestion by automatically scaling back the data transfer to match the available bandwidth capacity. Multiple concurrent and reliable data transfers across a shared network link may result in high congestion if each of the data transfer sessions tries to fully utilize the link capacity. This high congestion may result in high packet loss, which in turn may cause a large number of packet retransmissions, ultimately resulting in network collapse. TCP's congestion control algorithm avoids this problem by automatically determining how much bandwidth is available and sharing the total available bandwidth equally with other concurrent TCP sessions. TCP's dynamic sharing algorithm is therefore a fundamental building block of data communications across a packet switched internet protocol (IP) network and has resulted in the adoption of TCP/IP as a universal communications standard.
TCP utilizes various internal algorithms to provide its capability of congestion control. These algorithms include flow control, slow start, packet reordering, packet loss detection, retransmission timers, and numerous other mechanisms to dynamically decrease or increase the data transmission rate based on network conditions.
Network latency is a common problem that affects network and application performance. Network latency is attributable to several factors, including physical distance, number of hops, switching and router relays, and network congestion. Because these factors are not constants, networks may have unpredictable latency over a period of time. The variation in network latency depends on the distance spanned by the network link and the transmission medium used by the link. For instance, a local high-speed dedicated line between two buildings within a metro area may experience 5 milliseconds (ms) of one-way latency, while a global long distance asynchronous transfer mode (ATM) link between the United States and Europe may have anywhere from 50 to 250 ms of one-way latency. Similarly, a satellite link typically incurs about 240 to 300 ms of one-way latency, due to the time to transmit a signal up to an orbiting satellite and back.
The impact of latency on network applications may be traced directly to the inefficiencies of TCP under conditions of network latency. Most network applications can be classified into short-transaction based “chatty” applications or bulk data transfer applications. Bulk data transfer applications typically transmit 100s of kilobytes or megabytes of data across the network with the total transfer times being measured in several seconds, minutes, and in many cases hours. Examples of such applications include networked file systems, archiving and storage applications, file transfer protocol (FTP) transfers, sharing and distribution of large engineering or design documents, etc. In these applications, the common performance bottleneck is often the latency across the network, which causes lower application throughput via TCP. In particular, the flow control algorithm within TCP often causes the lower application throughput and higher application response time.
TCP's flow control algorithm is a mechanism to prevent the receiver from receiving more data than it is capable of processing or buffering. For example, if the receiving TCP stack has a buffer to store 16 kilobytes of data, the sender is not allowed to transmit more than 16 kilobytes of data at any time to the receiver. The receiver continuously sends back acknowledgments to the sender throughout the data transfer stating how much additional data the receiver can accept. This additional data that the receiver can accept is known as the “window indication” (or “window advertisement”) and is included as a field in the TCP header.
The flow control algorithm operates efficiently and does not introduce any unnecessary delays when the receiver and the sender are separated by a short distance low latency link. But as the distance and latency between the receiver and the sender is increased, the round-trip time (RTT) between sending a data packet and then receiving an acknowledgment from the receiver also increases. Since the flow control algorithm prevents the sender from transmitting data to the receiver when the receiver has not indicated that it is ready for this additional data, long RTTs between the two endpoints may cause the sender to delay sending additional data packets to wait for the next acknowledgment from the receiver. For example, if the receiver can accept 16 kilobytes of data at a time, then the sender may transmit all 16 kilobytes in a few milliseconds and then spend several additional milliseconds waiting for an acknowledgment to start transmitting the next block of 16 kilobytes. This period of time during which the sender is waiting for an acknowledgment depends on both the bandwidth and the link latency. The latency-based TCP idle time may cause a single TCP flow to achieve lower throughput than is actually available on the network link. This unused capacity translates into a higher transmission time since the TCP flow cannot utilize the full existing network bandwidth.
Flow pipelining is used for TCP connections that are limited in the rate at which they are able to transfer data because the maximum TCP window size configured on the receiver is smaller than the bandwidth-delay product of the network across which it is transferring the data. A conventional solution to this problem is for the receiver to advertise or indicate a window size that is bigger than the bandwidth-delay product of the network. However, for practical reasons, this indicated window size may be limited by the available memory on the receiver and the sender. As a result, a reasonable value is chosen by operating system developers and set as the default value of the window size. This value is adequate for most TCP connections across a local area network. But when a TCP connection is made across a high latency network, this value may not be adequate. The computers participating in the data transfer cannot dynamically discover and fix the small window size problem. This is because this problem can only be reliably observed by a device (which knows the bandwidth and current utilization of the long latency segment) processing data just before the longest latency segment of the network on the sender side. However, after this device determines that a particular transfer is window-limited, TCP provides no means for the device to inform the receiver that an increased window size is desired.
A solution that arbitrarily has the device increase the window size produces poor results because it generates a large amount of out of window data. Therefore, when there is a minor network error such as a single packet loss, this solution may cause a large amount of data that is outside of the receive window. The data that is outside of the receive window may be discarded by the receiver as it reaches the receiver. In addition to having the sender retransmitting the discarded data, it also causes the sender to misread the loss as a network congestion event and thus to slow down its transmission.
What is needed is a system and method for optimizing TCP's flow control to improve the performance of TCP sessions without intruding upon TCP's core algorithms.